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REAL PARTY IN INTEREST 



Appellants are unaware of any related appeals and interferences. 
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III. STATUS OF CLAIMS 

Claims 1-27 are pending and finally rejected in this Application. It is from the final 
rejection of claims 1-27 that this Appeal is taken. 

IV. STATUS OF AMENDMENTS 

The claims have not been amended subsequent to the imposition of the Final Office 
Action dated March 18, 2005, or the reopening of prosecution by the Examiner in the Office 
Action dated April 12, 2006. Although a Response was submitted pursuant to the provisions of 
37 C.F.R. § 1.1 16 on May 19, 2005, this Response did not make any changes or additions to the 
claims. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Referring to claims 1 and 12 and Figures 1 and 4 A, 4B of Appellants' specification, a 
method of establishing a persistent relationship between an end user device 101, 103 and a server 
109 where the server 109 is one of a plurality of servers 109 managed by a dispatcher 107 and 
the end user device 101, 103 accesses the server 109 using a uniform resource locator (URL) is 
disclosed. In step 401, a request for information from the end user device is received at the 
dispatcher 107, and the dispatcher 107 determines which of a plurality of servers 109 to select 
for satisfying the request (page 10, lines 12-15). In step 403, a token 235 is created at the 
selected server 109, and the token 235 includes at least an identifier 207 for the selected server 
109, a date/time stamp 209, and a key 211. The key 211 accesses a server-side storage area for 
information regarding the persistent relationship and the end user device (page 10, lines 16-25). 
In step 437, the token 235 is inserted into the URL (page 12, lines 1-9). In step 439, a response, 
with the token 235 inserted into the URL, is sent by the selected server 109 to the client device 
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101, 103. 

Referring to independent claims 7 and 18 and Figures 1 and 3 of Appellants' 
specification, a method of routing a request by an end user device 101, 103 to a particular one of 
a plurality of redundant servers 109 residing behind a network dispatching mechanism 107 is 
disclosed. In step 301, a request for information indicated by a uniform resource locator (URL) 
is received at the network dispatching mechanism 107 (page 12, line 16). In step 303, the 
network dispatching mechanism 107 determines if the URL contains a valid routing token 235 
(page 12, lines 17-18). In step 311, a determination is made at the network dispatching 
mechanism 107 as to whether the session binding indicated by the routing token 235 is old (page 
12, lines 21-22). In step 313, if the routing token 235 is not old, the network dispatching 
mechanism 107, forwards the request, including the URL, to the particular server 109 indicated 
by the valid routing token 235 (page 12, lines 26-27). 

The valid routing information from the URL is removed by the particular server 109 
(page 13, line 6). The particular server 109 stores the routing information removed from the 
valid routing token 235, and the valid routing information can be accessed subsequently by an 
outbound data stream filter during the processing of an outbound reply related to the request 
(page 13, lines 6-7). The particular server 109 accesses a server- side storage location where 
session information regarding a session between the particular server 109 and the end user device 
101, 103 is stored, and the accessed session information is inserted into the request (page 9, lines 
11-5). 

Referring to independent claims 10 and 20 and Figure 4B, a method of sending 
information to a requesting end user 101, 103 from an application over a session wherein the 
application resides at one of a plurality of redundant servers 109 residing behind a network 
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dispatcher 107 is disclosed. In step 421, response information including a URL (uniform 
resource locator) is received from the application (page 11, lines 8-10). In step 423, a 
determination is made if a server-side key cookie has been used for storing session information 
between the end user 101, 103 and the application (page 11, lines 10-14). In step 425, if server- 
side key cookie has been used for storing session information, a session key 211 from the key 
cookie is retrieved (page 11, line 14). In step 426, if a key cookie was not used for storing 
session information, a session key from a control block is retrieved. In step 427, all cookies are 
removed from the response information (page 10, lines 14-15). In step 429, the removed cookies 
are stored in a predetermined server-side storage area (page 11, lines 14-16). 

In step 43 1 , the URL is updated to indicate the removal of the cookies (page 1 1 , lines 20- 
27). In step 433, a sticky routing string is created (page 11, line 27 through page 12, line 1). In 
step 435, a date/time stamp in the sticky routing string is updated page 11, line 27 through page 
12, line 1). In step 437, the sticky routing string is inserted into the URL (page 12, lines 1-8). In 
step 439, the response information, including the URL, is transmitted to the end user 101.103 
(page 12, lines 8-9). 

Referring to independent claim 22 and Figures 1-2 and 4A, 4B of Appellants' 
specification, a network dispatcher 107 for establishing a persistent relationship between an end 
user device 101, 103 and a server 109 where the server 109 is one of a plurality of servers 109 
managed by the network dispatcher 107 is disclosed. Means are included for receiving a request 
for information from the end user device at the dispatcher, and means are included to determine 
which of a plurality of servers 109 to select for satisfying the request (page 10, lines 12-15). 
Means are included for creating the token 235, which includes at least an identifier 207 for the 
selected server 109, a date/time stamp 209, and a key 211. The key 211 accesses a server-side 
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storage area for information regarding the persistent relationship and the end user device 101, 
103 (page 10, lines 16-25). Means are included for inserting the token 235 into the URL (page 
12, lines 1-9), and means are included for sending, by the selected server 109, a response, with 
the token 235 inserted into the URL, to the client device 101, 103. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1 . Claims 1,12, and 22 were rejected under the second paragraph of 35 U.S.C. § 1 12; 

2. Claims 7 and 18 were rejected under 35 U.S.C. § 103 for obviousness based upon 
Courts et al, U.S. Patent No. 6,076,108 (hereinafter Courts), in view of Bellemore et al, U.S. 
Patent No. 6,088,728 (hereinafter Bellemore); 

3. Claims 8 and 19 were rejected under 35 U.S.C. § 103 for obviousness based upon 
Courts in view of Bellemore and Colby et al, U.S. Patent No. 6,006,264 (hereinafter Colby); 

4. Claims 10 and 20 were rejected under 35 U.S.C. § 103 for obviousness based upon 
Kunzelman et al, U.S. Patent No. 6,041,357 (hereinafter Kunzelman), in view of Courts and 
Bellemore; and 

5. Claims 11 and 21 were rejected under 35 U.S.C. § 103 for obviousness based upon 
Kunzelman in view of Courts, Bellemore, and Colby. 
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VII. ARGUMENT 



The Rejection of Claims 1, 12, and 22 under the Second Paragraph of 35 
U.S.C. §112 

For convenience of the Honorable Board in addressing the rejections, claims 12 and 22 
stand or fall together with independent claim 1 . 



On page 3 of the Fourth Office Action dated April 12, 2006 (hereinafter Fourth Office 

Action), the Examiner asserted the following: 

Claims 1, 12 and 22 are rejected under 35 U.S.C. 112, second paragraph, as being 
incomplete for omitting essential structural cooperative relationships of elements, such omission 
amounting to a gap between the necessary structural connections. See MPEP § 2172.01. 

The Examiner then proceeded to list four "structural cooperative relationships preceding the 

insertion of the token into the URL" that the Examiner asserted were omitted. 



For ease of reference, M.P.E.P. § 2172.01 is reproduced below: 

A claim which omits matter disclosed to be essential to the invention as described in the 
specification or in other statements of record may be rejected under 35 U.S.C. 1 12, first paragraph, 
as not enabling. In re Mayhew, 527 F.2d 1229, 188 USPQ 356 (CCPA 1976). See also MPEP 
§ 2164.08(c). Such essential matter may include missing elements, steps or necessary structural 
cooperative relationships of elements described by the applicant(s) as necessary to practice the 
invention. 

In addition, a claim which fails to interrelate essential elements of the invention as defined by 
applicant(s) in the specification may be rejected under 35 U.S.C. 112, second paragraph, for 
failure to point out and distinctly claim the invention. See In re Venezia, 530 F.2d 956, 189 USPQ 
149 (CCPA 1976); In re Collier, 397 F.2d 1003, 158 USPQ 266 (CCPA 1968). >But see Ex parte 
Nolden, 149 USPQ 378, 380 (Bd. Pat. App. 1965) ("[I]t is not essential to a patentable 
combination that there be interdependency between the elements of the claimed device or that all 
the elements operate concurrently toward the desired result"); Ex parte Huber, 148 USPQ 447, 
448-49 (Bd. Pat. App. 1965) (A claim does not necessarily fail to comply with 35 U.S.C. 112, 
second paragraph where the various elements do not function simultaneously, are not directly 
functionally related, do not directly intercooperate, and/or serve independent purposes.). < 

At the outset, Appellants note that the case law referred to above generally applies to "kit" or 
"assembly" claims. Independent claims 1, 12, and 22, however, are respectively directed to a 
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method, a computer program product, and a network dispatcher, which on their face do not 
appear to be kit or assembly claims. 

Moreover, as summarized in above-reproduced passages, the case law requires that the 
alleged omitted essential matter be identified by Appellants as "essential" within the 
"specification" or within "other statements of record." The Examiner, however, has failed to 
establish that the four features alleged by the Examiner to be omitted, have been identified, by 
Appellants, as being essential. 

Furthermore, Appellants surmise that the Examiner has misinterpreted the enablement 
requirement of the first paragraph of 35 U.S.C. § 112, as the Examiner appears to be requiring 
that the independent claims enable the invention. This requirement, however, is not consonant 
with the first paragraph of 35 U.S.C. § 1 12, which only requires that the specification describe how 
to make and use the invention. 

For the reasons stated above, Appellants respectfully submit that the Examiner has failed to 
establish a proper rejection under the second paragraph of 35 U.S.C. § 1 12. 

The Rejection of Claims 7 and 18 under 35 U.S.C. § 103 for Obviousness based 
upon Courts in view of Bellemore 

For convenience of the Honorable Board in addressing the rejections, claim 18 stands or 
falls together with independent claim 7. 
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Appellants respectfully submit that the Examiner has failed to discharge the initial burden 
of establishing a prima facie basis to deny patentability to the claimed invention under 35 U.S.C. 
§ 103. 1 In rejecting a claim under 35 U.S.C. § 103, the Examiner is required to identify a source in 
the applied prior art for: (1) claim limitations; and (2) the motivation to combine references or 
modify a reference in the reasonable expectation of achieving a particular benefit. 2 In so doing, it is 
legally erroneous to ignore any claim limitation. 3 

Independent Claim 7 

Appellants respectfully submit that the Examiner has improperly relied upon the applied 
prior art to teach certain of the claimed limitations; and thus, the Examiner has failed to establish 
that the applied prior art teaches or suggests all of the claim limitations. 

On page 4 of the Fourth Office Action, the Examiner cited column 6, line 45 of Courts to 
teach if a session binding is old (i.e., the claimed "determining, at the network dispatching 
mechanism, if a session binding indicated by said routing token is old"). For ease of reference, 
column 6, lines 43-48 of Courts is reproduced below: 

Engine manager 120 is the system element that receives requests from the broker 102, binds the 
request to an available render engine 122, delivers the request to a render engine 122, receives the 
results from the render engine 122, and delivers the results back to broker 102. 

A review of this cited passage does not yield any teaching of a determination that a session 
binding, as indicated by a routing token, is old. Therefore, the Examiner has improperly asserted 
that Courts discloses the above-identified claimed limitation. 



1 InreMavne . 104 F.3d 1339, 41 USPQ2d 1451 (Fed. Cir. 1997); In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 
(Fed. Cir. 1992). 

2 Smiths Industries Medical System v. Vital Signs Inc. , 183 F.3d 1347, 51 USPQ2d 1415 (Fed. Cir. 1999). 

3 Uniroyal, Inc. v. Rudkin- Wiley Corp. , 837 F.2d 1044, 5 USPQ2d 1434 (Fed. Cir. 1988). 
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On page 4 of the Fourth Office Action, the Examiner cited column 3, line 5-7 and column 

6, line 4 of Courts to teach the claimed "forwarding, by said network dispatching mechanism, the 

request, including the URL, to the particular server." For ease of reference, column 3, lines 5-7 

and column 5, line 66 through column 6, line 5 of Courts are reproduced below: 

Interaction layer 12 can be responsible for enforcing security, managing sessions, and distributing 
request to the most available servers. 

As shown in FIG. 2A, a load distribution unit 98 receives user URL requests. Load distribution 
unit 98 then distributes each URL request to one of a plurality of physical computer systems for 
processing. In one implementation, load distribution unit 98 can be a CISCO Front End Local 
Director which uses a "round robin" or "least connections" algorithm for routing requests. 

Although Courts teaches distributing a URL request, the claimed limitation also recites that in 
addition to the request, the actual URL is also forwarded to the particular server. However, the 
Examiner has not established that Court explicitly or inherently (i.e., necessarily) teaches that the 
actual URL, which generates the request, is forwarded along with the request to the particular 
server. Therefore, the Examiner has improperly asserted that Courts teaches the claimed 
"forwarding, by said network dispatching mechanism, the request, including the URL , to the 
particular server" (emphasis added). 

As already noted above, the Examiner has not established that the request, including the 
URL, is forwarded to the particular server. With regard to the URL, independent claim 7 further 
recites: 

removing, by said particular server, said valid routing information from 
the URL; 

storing, by said particular server, said routing information removed from 
said valid routing token, where said valid routing information can be accessed 
subsequently by an outbound data stream filter during the processing of an 
outbound reply related to said request; 
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On pages 4 and 5 of the Fourth Office Action, the Examiner cited column 1, lines 48-53 
of Courts to teach the above -identified limitations. For ease of reference column 1, lines 48-53 is 
reproduced below: 

Session data representing a state of the user session is stored in memory in a global session server. 
Then, for each subsequent request associated with the user session, the subsequent request is 
received, and the session data is retrieved from the global session server. 

Not only has the Examiner failed to establish that a request, including an URL, is forwarded to a 

server. The citation reproduced above also fails to teach that valid routing information is 

removed from the URL by the server. This citation within Courts also fails to teach that the 

routing information removed from the URL is stored and can be accessed subsequently by an 

outbound data stream filter during the processing of an outbound reply related to the request. 

Appellants also note that the Examiner has not clearly identified those elements within Courts 

being relied upon. For example, the Examiner has not identified the outbound data stream filter. 

In this regard, the Examiner's rejection under 35 U.S.C. § 103 also fails to comply with 37 C.F.R. § 

1.104(c). 4 



In the first full paragraph on page 5 of the Fourth Office Action, the Examiner asserted 

that: 

Court et al. does not teach of tokens and inserting, by said particular server, said session 
information into said request and accessing, by said particular server, a server-side storage 
location where session information regarding a session between the particular server and the end 
user device is stored. However, Bellemore et al teach the incorporation of session information in 
the queries received by the clients (column 4, lines 21-43, column 8 lines 6-38, column 12 lines 
55-67, column 16 lines 10-66, column 17 lines 14-54) and server-side storage where information 
about the session and the user is stored (column 2 lines 2-50, column 6 line 47 - column 7 line 7, 



4 37 C.F.R. § 1.104(c) provides: 

In rejecting claims for want of novelty or for obviousness, the examiner must cite the best 
references at his or her command. When a reference is complex or shows or describes inventions 
other than that claimed by the applicant, the particular part relied on must be designated as nearly 
as practicable. The pertinence of each reference, if not apparent, must be clearly explained and 
each rejected claim specified. 
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column 13, lines 43-64). 

At the outset, Appellants note that the Examiner's citation of column 4, lines 21-43 is found in 
the "Summary of the Invention" portion of Bellmore and provides little guidance as to those 
features within Bellemore that the Examiner is relying upon to teach the claimed invention. 
Moreover, the Examiner has cited nearly two additional columns of text to allegedly teach "the 
incorporation of session information in the queries received by the clients." Notwithstanding 
that these passages within Bellemore do not teach or suggest the limitations not disclosed by 
Courts, the Examiner has not clearly identified the individual elements within Bellemore being 
relied upon, and thus, the rejection further fails to comply with 37 C.F.R. §1.1 04(c). 

Upon reviewing Bellemore, Appellants note that although Bellmore teaches the use of 
"an identifier designating the server to which the client desires to long in" (column 16, lines 24- 
25), Appellants are unable to discover any teaching or suggestion that the "identifier" taught by 
Bellemore is found in a URL so as to correspond to the claimed "determining, at the network 
dispatching mechanism, if said URL contains a valid routing token." Moreover, Appellants have 
been unable to discover any teaching or suggestion by Bellemore that a determination is made as 
to whether or not the "identifier" is valid. Since, as admitted by the Examiner, Court et al. does 
not teach of tokens and inserting, even if one having ordinary skill in the art were motivated to 
combine Bellemore with Courts, the claimed invention would not result because Bellmore and 
Courts, either alone or in combination, fail to teach the claimed "determining, at the network 
dispatching mechanism, if said URL contains a valid routing token." 

Therefore, even if the applied prior art were combined in the manner suggested by the 
Examiner, the claimed invention would not result since the Examiner has not established that the 



11 



Application No.: 09/557,708 

applied prior art teaches all of the claimed limitations recited in claim 7. Independent claim 18 
includes similar limitations to those recited in claim 7 and is patentable over the applied prior art 
at least for the same reasons. Appellants, therefore, respectfully submit that the imposed 
rejection of claims 7 and 18 under 35 U.S.C. § 103 for obviousness based upon Courts in view of 
Kunzelman and Smith is not viable. 

The Rejection of Claims 8 and 19 under 35 U.S.C. § 103 for Obviousness based 
upon Courts in view of Bellemore and Colby 

For convenience of the Honorable Board in addressing the rejections, claims 8 and 19 
stand or fall together with independent claim 7. 

Claims 8 and 19 respectively depend from independent claims 7 and 18, and Appellants 
incorporate herein the arguments previously advanced in traversing the imposed rejection of claims 
7 and 18 under 35 U.S.C. § 103 for obviousness based upon Courts in view of Bellemore. 
Specifically, even if the applied prior art were combined in the manner suggested by the 
Examiner, the claimed invention would not result since the Examiner has not established that the 
applied prior art teaches all of the claimed limitations recited in claims 7 and 18. The additional 
reference to Colby does not cure the deficiencies of the combination of Courts in view of 
Bellemore. Accordingly, the proposed combination of references would not yield the claimed 
invention. Appellants, therefore, respectfully submit that the imposed rejection of claims 8 and 
19 under 35 U.S.C. § 103 for obviousness based upon Courts in view of Bellemore and Colby is 
not viable. 
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The Rejection of Claims 10 and 20 under 35 U.S.C. § 103 for Obviousness 

BASED UPON KUNZELMAN IN VIEW OF COURTS AND BELLEMORE 

For convenience of the Honorable Board in addressing the rejections, claim 20 stands or 
falls together with independent claim 10. 

Independent claim 10 recites "removing all cookies from said response information; 
storing said removed cookies in a predetermined server-side storage area." In the paragraph 
spanning pages 14 and 15 of the Final Office Action, the Examiner cited column 2, lines 55-57; 
column 5, lines 38-62; and column 6, lines 43-57 of Kunzelman to teach these limitations, 
among others. At the outset, Appellants note that the Examiner has not clearly identified those 
elements within Kunzelman being relied upon. In this regard, the Examiner's rejection under 35 
U.S.C. § 103 fails to comply with 37 C.F.R. § 1.104(c). 

Notwithstanding the ambiguity of the Examiner's assertions regarding Kunzelman, a 
review of the Examiner's citation fails to yield any teaching that all cookies are removed from 
response information and that these removed cookies are stored in a predetermined server-side 
storage area. Therefore, the Examiner has improperly asserted that Kunzelman discloses the 
above -identified claimed limitations. 

Since the Examiner has not established that the applied prior art teaches all of the claimed 
limitations recited in claim 10, the proposed combination of references would not yield the claimed 
invention. Independent claim 20 includes similar limitations to those recited in claim 10 and is 
patentable over the applied prior art at least for the same reasons. Appellants, therefore, 
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respectfully submit that the imposed rejection of claims 10 and 20 under 35 U.S.C. § 103 for 
obviousness based upon Kunzelman in view of Courts and Bellemore is not viable. 

The Rejection of Claims 11 and 21 under 35 U.S.C. § 103 for Obviousness 
based upon Kunzelman in view of Courts , Bellemore, and Colby 

For convenience of the Honorable Board in addressing the rejections, claims 1 1 and 20 
stand or fall together with independent claim 10. 

Claims 11 and 21 respectively depend from independent claims 10 and 20, and Appellants 
incorporate herein the arguments previously advanced in traversing the imposed rejection of claims 
10 and 20 under 35 U.S.C. § 103 for obviousness based upon Kunzelman in view of Courts and 
Bellemore. Specifically, even if the applied prior art were combined in the manner suggested by 
the Examiner, the claimed invention would not result since the Examiner has not established that 
the applied prior art teaches all of the claimed limitations recited in claims 11 and 21. The 
additional reference to Colby does not cure the deficiencies of the combination of Kunzelman in 
view of Courts and Bellemore. Accordingly, the proposed combination of references would not 
yield the claimed invention. Appellants, therefore, respectfully submit that the imposed rejection 
of claims 11 and 21 under 35 U.S.C. § 103 for obviousness based upon Kunzelman in view of 
Courts, Bellmore, and Colby is not viable. 

Conclusion 

Based upon the foregoing, Appellants respectfully submit that the Examiner's rejections 
under 35 U.S.C. §§ 103, 1 12 are not factually or legally viable. Appellants, therefore, respectfully 
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solicit the Honorable Board to reverse the Examiner's rejections under 35 U.S.C. §§ 103, 1 12. 



To the extent necessary, a petition for an extension of time under 37 C.F.R. § 1.136 is 
hereby made. Please charge any shortage in fees due under 37 C.F.R. §§ 1.17, 41.20, and in 
connection with the filing of this paper, including extension of time fees, to Deposit Account 09- 
0461, and please credit any excess fees to such deposit account. 



Date: September 21, 2006 Respectfully submitted, 



/Scott D. Paul/ 

Scott D. Paul 
Registration No. 42,984 
Steven M. Greenberg 
Registration No. 44,725 
CUSTOMER NUMBER 46320 
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VIII. CLAIMS APPENDIX 

1 . A method of establishing a persistent relationship between an end user device and a 
server where the server is one of a plurality of servers managed by a dispatcher and the end user 
device accesses the server using a uniform resource locator (URL), the method comprising the 
steps of: 

receiving at the dispatcher, a request for information from the end user device; 
determining by the dispatcher, which of the plurality of servers to select for satisfying the 
request; 

creating, at the selected server, a token comprising at least an identifier for the selected 
server, a date/time stamp, and a key, said key for accessing a server-side storage area for 
information regarding the persistent relationship and the end user device; 

inserting the token into the URL; and, 

sending, by the selected server to the client device, a response with the token inserted into 
the URL. 

2. A method as claimed in claim 1 wherein said token is encoded using a modified 
Base64 encoding. 

3. A method as claimed in claim 1 wherein said token has a checksum or hash 
verification field. 

4. A method as claimed in claim 3 wherein said hash is a SHA-1 hash computed over 
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said identifier for said selected server, said date/time stamp, and said key. 

5. A method as claimed in claim 3 wherein said checksum or hash is encoded using a 
modified Base64 encoding. 

6. A method as claimed in claim 1 wherein said information regarding said persistent 
relationship is stored as a cookie on said server. 

7. A method of routing a request by an end user device to a particular one of a plurality 
of redundant servers residing behind a network dispatching mechanism, said methods comprising 
the steps of: 

receiving, at the network dispatching mechanism, a request for information indicated by a 
uniform resource locator (URL); 

determining, at the network dispatching mechanism, if said URL contains a valid routing 

token; 

if said URL contains a valid routing token, further determining, at the network 
dispatching mechanism, if a session binding indicated by said routing token is old; 

if said URL contains a valid routing token and said routing token is not old, forwarding, 
by said network dispatching mechanism, the request, including the URL, to the particular server 
indicated by said valid routing token; 

removing, by said particular server, said valid routing information from the URL; 

storing, by said particular server, said routing information removed from said valid 
routing token, where said valid routing information can be accessed subsequently by an 
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outbound data stream filter during the processing of an outbound reply related to said request; 

accessing, by said particular server, a server-side storage location where session 
information regarding a session between the particular server and the end user device is stored; 
and, 

inserting, by said particular server, said accessed session information into said request. 

8. A method as claimed in claim 7 wherein additional filtering of the URL is done prior 
to the forwarding step. 

9. A method as claimed in claim 1 wherein all filtering is performed within the 
dispatcher. 

10. A method of sending information to a requesting end user from an application over a 
session wherein said application resides at one of a plurality of redundant servers residing behind 
a network dispatcher, said method comprising the steps of: 

receiving response information from said application, said response information 
including a URL (uniform resource locator); 

determining if a server-side key cookie has been used for storing session information 
between said end user and said application; 

if a server-side key cookie has been used for storing session information, retrieving a 
session key from said key cookie; 

if a key cookie was not used for storing session information, retrieving said session key 
from a control block; 
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removing all cookies from said response information; 

storing said removed cookies in a predetermined server-side storage area; 

updating said URL to indicate the removal of said cookies; 

creating a sticky routing string; 

updating a date/time stamp in said sticky routing string; 
inserting said sticky routing string into said URL; and, 
transmitting said response information, including said URL to said end user. 

11. A method as claimed in claim 10 wherein, prior to said determining step, said 
response information is transmitted from said application through one or more filters. 

12. A computer program product having computer readable code means of establishing a 
persistent relationship between an end user device and a server where the server is one of a 
plurality of servers managed by a dispatcher and the end user device accesses the server using a 
uniform resource locator (URL), the computer program product comprising: 

computer readable code means of receiving at the dispatcher, a request for information 
from the end user device; 

computer readable code means of determining by the dispatcher, which of the plurality of 
servers to select for satisfying the request; 

computer readable code means of creating, at the selected server, a token comprising at 
least an identifier for the selected server, a data/time stamp, and a key, said key for accessing a 
server-side storage area for information regarding the persistent relationship and the end user 
device; 
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computer readable code means of inserting the token into the URL; and, 
computer readable code means of sending, by the selected server to the client device, a 
response with the token inserted into the URL. 

13. A computer program product as claimed in claim 12 wherein said token is encoded 
using a modified Base64 encoding. 

14. A computer program product as claimed in claim 12 wherein said token has a 
checksum or hash verification field. 

15. A computer program product as claimed in claim 14 wherein said hash is a SHA-1 
hash computed over said identifier for said selected server, said date/time stamp, and said key. 

16. A computer program product as claimed in claim 14 wherein said checksum or hash 
is encoded using a modified Base64 encoding. 

17. A computer program product as claimed in claim 12 wherein said information 
regarding said persistent relationship is stored as a cookie on said server. 

18. A computer program product having computer readable code means for routing a 
request by an end user device to a particular one of a plurality of redundant servers residing 
behind a network dispatching mechanism, said computer program product comprising: 

computer readable program code for receiving, at the network dispatching mechanism, a 
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request for information indicated by a uniform resource locator (URL); 

computer readable program code for determining, at the network dispatching mechanism, 
if said URL contains a valid routing token; 

if said URL contains a valid routing token, computer readable program code for further 
determining, at the network dispatching mechanism, if a session binding indicated by said 
routing token is old; 

if said URL contains a valid routing token and said routing token is not old, computer 
readable program code for forwarding, by said network dispatching mechanism, the request, 
including the URL, to the particular server indicated by said valid routing token; 

computer readable program code for removing, by said particular server, said valid 
routing information from the URL; 

computer readable program code for storing, by said particular server, said routing 
information removed from said valid routing token, where said valid routing information can be 
accessed subsequently by an outbound data stream filter during the processing of an outbound 
reply related to said request; 

computer readable program code for accessing, by said particular server, a server-side 
storage location where session information regarding a session between the particular server and 
the end user device is stored; and, 

computer readable program code for inserting, by said particular server, said accessed 
session information into said request. 

19. The computer program product as claimed in claim 18 wherein additional filtering of 
the URL is done prior to the forwarding step. 
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20. A computer program product having computer readable code means of sending 
information to a requesting end user from an application over a session wherein said application 
resides at one of a plurality of redundant servers residing behind a network dispatcher, said 
computer program product comprising: 

computer readable programming means of receiving response information from said 
application, said response information including a URL (uniform resource locator); 

computer readable programming means of determining if a server-side key cookie has 
been used for storing session information between said end user and said application; 

if a server-side key cookie has been used for storing session information, computer 
readable programming means of retrieving a session key from said key cookie; 

if a key cookie was not used for storing session information, computer readable 
programming means of retrieving said session key from a control block; 

computer readable programming means of removing all cookies from said response 
information; 

computer readable programming means of storing said removed cookies in a 
predetermined server-side storage area; 

computer readable programming means of updating said URL to indicate the removal of 
said cookies; 

computer readable programming means of creating a sticky routing string; 
computer readable programming means of updating a date/time stamp in said sticky 
routing string; 

computer readable programming means of inserting said sticky routing string into said 
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URL; and, 

computer readable programming means of transmitting said response information, 
including said URL to said end user. 

21. A computer program product as claimed in claim 20 wherein, prior to said 
determining step, said response information is transmitted from said application through one or 
more filters. 

22. A network dispatcher for establishing a persistent relationship between an end user 
device and a server where the server is one of a plurality of servers managed by said network 
dispatcher comprising: 

means for receiving a request for information from said end user device, said request for 
information including a uniform resource locator (URL); 

means for determining which of the plurality of servers to select for satisfying said 
request for information; 

means for creating, at said selected server, a token comprising at least an identifier for the 
selected server, a date/time stamp, and a key, said key for accessing a server-side storage area for 
information regarding the persistent relationship and the end user device; 

means for inserting the token into the URL; and, 

means for sending, by the selected server, a response with the token inserted into the 
URL to the client device. 

23. A network dispatcher as claimed in claim 22 wherein said token is encoded using a 
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modified Base64 encoding. 

24. A network dispatcher as claimed in claim 22 wherein said token has a checksum or 
hash verification field. 

25. A network dispatcher as claimed in claim 24 wherein said hash is a SHA-1 has 
computed over said identifier for said selected server, said date/time stamp, and said key. 

26. A network dispatcher as claimed in claim 24 wherein said checksum or hash is 
encoded using a modified Base64 encoding. 

27. A network dispatcher as claimed in claim 22 wherein said information regarding the 
persistent relationship is stored as a cookie on said server. 
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IX. EVIDENCE APPENDIX 

No evidence submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132 of this title or of 
any other evidence entered by the Examiner has been relied upon by Appellants in this Appeal, 
and thus no evidence is attached hereto. 
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X. RELATED PROCEEDINGS APPENDIX 

Since Appellants are unaware of any related appeals and interferences, no decision 
rendered by a court or the Board is attached hereto. 
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